In order to manage usage of network resources, a network may implement policy control mechanisms. For example, 3GPP (Third Generation Partnership Project) mobile networks are provided with a Policy and Charging Control (PCC) architecture. Details of the PCC architecture can be found in 3GPP Technical Specification (TS) 23.203. The PCC architecture allows the operators to achieve real-time control of their network resources, control subscriber access to services, and proactively optimize network capacity. Elements of the PCC architecture include a policy controller, referred to as Policy and Charging Rules Function (PCRF), a Policy Enforcement Function (PCEF) and/or a Bearer Binding and Event Reporting Function (BBERF), and an Application Function (AF).
The PCRF provides network control regarding service data flow detection, gating, Quality of Service (QoS), and flow based charging. This control involves controlling enforcement of PCC rules by the PCEF and/or controlling enforcement of QoS rules by the BBERF, e.g., by creating PCC rules and installing them in the PCEF, by creating QoS rules and installing them in the BBERF, or by activating or deactivating installed PCC rules or QoS rules.
The AF is an element offering packet-based services or applications that require packet-based transfer of data to or from a user equipment (UE). The PCC architecture allows for subjecting this packet-based transfer of data to dynamic policy and/or charging control. For this purpose, the AF may communicate with the PCRF to transfer information related to the service. The PCRF may use this information for making control decisions.
For example, when the AF needs to transfer data of a service or application to or from the UE, the AF may communicate with the PCRF to request to authorization of the service. The PCRF may then authorize the service, create the corresponding PCC/QoS rules and install them in the PCEF or BBERF.
Alternatively, the PCRF may not authorize the service. The decision to refuse authorization of the service may be based on different criteria, e.g., as defined in a subscription profile of a user. The PCRF may indicate the reason why the service was not authorized to the AF. Based on this information, the AF may take different actions, e.g., reattempt authorization of the service after a period of time.
In some scenarios, the conditions forming the basis of rejecting authorization of the service may change. For example, if the rejection was due to the subscriber belonging to a category not allowed to use a certain service, the category of the subscriber may be changed by the operator. Further, if the rejection was due to the UE roaming in a visited network in which case usage of a certain service is not allowed by roaming agreements, the UE may move back to its home network, in which case usage of the service would be allowed again. Further, if the authorization was rejected due to a quota of the subscriber being used up, the subscriber could refill the quota.
However, the AF typically does not know when such a change of conditions occurs. Accordingly, frequent rejections may occur if the AF blindly reattempts authorization of the service. On the other hand, if the AF does not reattempt authorization of the service, otherwise allowed usage of the service could be prohibited.
Accordingly, there is a need for techniques which allow for efficiently authorizing a service in a mobile network.